超级干货：适用于大中型银行的云原生技术体系建设方案
【作者】2021容器云职业技能大赛参赛团队“三地五中心队” 队员：孙佳明 兴业数金 容器云工程师、李逍 兴业银行 应用运维工程师、林钫 兴业数金 系统运维工程师、林鑫 兴业数金 容器云工程师、王嵩阳 兴业银行 质量中心工程师
目录
1 方案背景
2 需求分析
3 方案整体设计
4 打造金融级容器云基建
4.1 容器云平台设计
4.2 高性能云原生存储方案
4.3 金融级云原生网络方案
4.4 高可用及容灾设计
5 通过 PaaS 层能力为研发提供统一技术服务
5.1 基于容器云资源池提供中间件 PaaS 服务
5.2 多云异构微服务治理
6 云原生体系下的安全合规交付体系设计
6.1 云原生交付体系整体设计
6.2 DevSecOps 实践安全合规交付
6.3 应用开发平台/框架实现一键云原生改造
6.4 企业级制品库作为交付中枢
7 云原生运营监控手段
7.1 运维体系整体设计
7.2 多云监控运营方案设计
7.3 集中日志平台设计
7.4 适配云环境的 CMDB 设计
7.5 基于 EBPF 增强可观测性
7.6 基于 AIOPS 的智能运维体系
8 企业级云原生知识体系建设
8.1 云原生 Wiki 设计
8.2 ChatOps 构建知识搜索体系
8.3 云原生文化建设
9 云原生标准建设
9.1 高阶指引
9.2 研发侧规范
9.3 业务上云交付规范
9.4 运维侧规范
10 总结与展望
1 方案背景
在数字化转型新形势下，银行信息系统面临诸多诉求和考验。银行的业务应用目前以多种形态运行在不同的技术栈上，包括互联网技术栈和商业技术栈。大多数系统已经完成新一代的升级，但是随着云原生技术的发展，很多银行开始试水分布式架构体系改造。
由于银行交易往往比较重要，有哪些系统最适合云原生容器化改造，应用在进行改造后如何符合银行现有规范等问题也显露出来：
云原生新技术难：对容器技术没接触或接触少的研发部门会面临新技术的学习成本高，改造难度大等问题。
上云高可用及安全管控难：互联网技术栈产品直接进入不符合银行的高可用及安全要求等。
不同技术栈应用上云治理难：容器改造期间可能涉及到除容器以外的其他平台或云产品。
制品管理及投产流程繁琐：投产审核开发测试环节中生成的制品、编排文件需要经过安全审核再投产。
多云资源管理难：资源申请面临不同云平台产品的统一供给问题。
运维难度大：运维部门需要在现有运维框架下如何更快上手，并减少运维难度问题。
2 需求分析
关键需求一：金融级云原生平台，一站式上云体系化支撑
为了更好的保障银行业务应用的稳定性以及满足技术先进性的需求， 容器云平台需便捷支持上云业务高可用部署，满足银行级业务的的高可用需求；适用于多种业务场景且满足不同技术栈产品的快速迁移需求；具备统一化规范化管理的能力实现技术支撑降本增效。
一是需在建设一套满足不同项目使用需求的容器云管平台， 实现对多容器环境资源的统一管理；二是集成主流容器编排引擎和容器主机、存储、网络、服务发现等组件，实现多环境下容器的统一管理、调度和弹性伸缩；三是强有力的云原生存储及网络方案加持，实现容器云基础设施更强的扩展性，可有力支撑各类型企业级 PaaS 服务建设。
关键需求二：合规、便捷的研发交付体系，能支撑银行业务快速转型上云
为实现银行业务基于容器实现快速、标准化交付，交付体系建设在平台功能上、流程设计上都需要进行考虑。
在功能性方面。一是实现基于容器的应用编排和应用生命周期管理，实现应用一键部署和升级，实现应用可视化管理、智能调度、弹性伸缩、健康检查，监控和告警；二是集成常用容器管理工具，包括容器镜像仓库、应用商店、CI／CD工具、集中监控告警、日志采集分析等，以提高容器应用的管理和运维水平；三是便于研发人员导出统一的编排文件、配置文件以及制品；四是提供常用的基础技术 PaaS 服务；五是具备不同技术栈应用上云且在多集群环境下的通用服务治理能力；六是统一的云原生应用开发平台，便于银行自研应用从研发即云原生，为 Serverless 奠定基础。
在流程设计方面。一是统一制品发布流程，制定制品和编排文件规范，在投产前完成安全合规检查；二是统一的 CI/CD 流程，在流程中支持自动制品规范扫描、安全扫描等步骤，并满足快速发布到不同测试环境，并经过投产流程的自动审核。
关键需求三：通过自动化降低运维复杂度
云基础设施向下与存储、网络架构关系紧密，向上与应用的耦合度也比传统虚机、物理机 IaaS 更紧密，技术复杂度高，运维难度大。一是资源管控，统一资源申请平台， 基于标准化的模板满足测试和生产环境不同环境下多平台资源的统一供给能力；二是通过技术手段加强可观测性，便于快速故障排查；三是通过企业级 CMDB，推动运维自动化及 AIOPS 提升运维效率。
关键需求四：云原生架构转型下的全员新知识体系推广
企业的 IT 基础架构转型，需要研发、运维人都对云原生技术有正确的认识和理解。建立统一知识库，满足研发部门的快速上手等需求，同时建立运维知识体系，使问题解决方案随时可查是一个有效策略，并建议加以体系化培训、技能认证等手段支撑。
通过指引以点到面推广，如新建系统应直接采用云原生架构设计，避免历史技术债，降低迁移成本，为各类型业务上云铺路；根据应用实际场景定位是否符合云原生场景，划分为敏态、稳态，从对应技术架构和服务响应角度综合考虑哪些节点适合容器部署；逐步实现全面云化转型。
通过规范保障研发、交付、运维流程的合理运行，更好发挥云基础设施的效能。
3 方案整体设计
本文方案设计的云原生技术体系全景
本文的方案设计从以下六个方面展开介绍：
打造金融级容器云基建
银行 IT 基础设施对高可用、稳定可靠有较高的要求，基于传统的 IaaS 部署应用已有相对成熟的解决方案，如存储层镜像复制、虚拟机漂移、全局 DNS 切换等。基于容器技术建设的云基础设施具备更优的资源利用率和弹性优势，但云原生技术体系仍在快速发展过程中，如何利用容器技术打造高可用、稳定可靠的IT 基础设施，各企业需求存在不同的解法，本文方案设计了多云管理、Runtime 改进、高性能云原生存储、金融级容器网络、容器云容灾系统等系列方案进行容器云基础设施建设，并使其具备支撑企业级 PaaS 的扩展性能力。
通过 PaaS 层能力为研发提供统一技术服务
一是通过基础技术平台为上云业务一键提供常用开源中间件服务， 省去业务系统建设重复造轮子的过程；二是提供不同技术架构分布式体系的多云环境下的服务治理能力，为不同技术栈的系统上云扫清障碍。
安全合规下的高效交付体系
银行业务较多且复杂，很难迅速规模化服务化，欲快速规模化推进银行的传统业务系统容器化迁移，发挥云化基础设施效能，建立切实可行且便于研发、管理、运维人员上手的交付体系也非常关键。
本文方案通过统一的云原生应用开发平台使自研应用从头云原生，为 Serverless 奠定基础；企业制品仓库（Artifactory）为交付体系的中枢，搭建 DevSecOps 体系打通应用上云的制品流转、自动化安全合规审核。
加强云原生运维手段
容器云基础设施上应用以进程形式存在，与基础设施耦合性增强，变化性也较强。本文方案建设企业级 CMDB 对接容器云基础设施，针对上云的应用建设适配的监控告警平台、统一日志平台，保障在应用部署形态发生变化下的可观测能力，基于 EBPF 技术进一步增强可观测性，使用 AIOPS 技术自动化实现应用上云的资源分配、管理流程，智能进行故障分析处理，提升运维效率。
企业级云原生知识体系建设
技术转型，意识先行，云原生技术体系重塑企业 IT 基础设施的同时，也涉及银行科技条线各职能人员的习惯与职责变化， 各个岗位人员对云原生技术正确的认识，才能落地好云原生全面提升 IT 效能。本文方案通过建立云原生 Wiki、知识迭代体系，结合学习、培训、认证机制，来实现上述目标。
云原生标准建设
本文方案通过研发侧规范制定应用容器改造、构建、部署要求，保障应用设计的云原生化，可较好适应基础设施的弹性、韧性特点；通过交付规范保障上云生命周期的安全合规即高效；通过运维侧规范优化容器云资源管理，提升利用率降本增效，保障容器平台层、PaaS 层、应用层可靠运行。
4 打造金融级容器云基建
4.1 容器云平台设计
容器云整体规划
4.1.1 各 AZ 建设多集群，统一管理
首先银行的业务场景非常的广泛，存在在线业务、离线作业，还需有部分需要 GPU 的业务；一些中间件， 数据库它对底层的网络容器存储的需求是不同的，势必会需要不同的解决方案，因此我们需要为不同的业务场景定制不同集群（如CPU 密集型、内存密集型、GPU 型）。
第二是受 K8S 本身性能的限制，包括 Scheduler、Etcd、API Server 等组件的瓶颈，在满足性能的情况下每个集群有容量上限。
第三是银行内多网络域管控需求， 如建设单一大集群区域与区域之间的网络抖动或者延迟有可能造成 master 节点和 node 节点失联， 业务重新调度等问题。
第四是容器云集群 K8S 引擎本身因可能存在崩溃风险，且云原生技术体系发展迅速，集群级的维护在所难免，需考虑在同 AZ 默认将应用部署至至少 2 个集群上。
本方案采用各个网络域搭建多集群，以支持多层次故障保护机制，确保两地三中心的不同资源域有一致的容器资源池，确保单个存储、单个集群甚至单个数据中心发生故障时，不会影响业务的整体可用性。使用统一多云管理平台统一纳管多套 K8S 集群，集群与集群之间的业务调度、容灾备份等都在这个多云管理平台上实现。
4.1.2 基于 K8S 原生 API 实现集中高效多云管理
随着集群数量的增长，对集群的运维、管理带来了新的挑战：包括集群繁多的重复劳动、业务过度分散的维护难题、业务跨云访问以及集群间的应用同步难以管理；且应用的可用性受限于集群，资源调度、弹性伸缩均受限于集群，缺少自动化故障迁移。
多云容器编排项目 Karmada（Kubernetes Armada）与今年 4 月正式开源， 部分行业人的头部企业中已有落地经验。该项目具备集群整体的生命周期管理、 集群注册、 多集群伸缩、 多集群调度、 整体统一的 API、 底层标准 API 支持，它都是 CNI/CSI 在它整体功能视图里， 包括上层的应用、 对 Istio、 Mash、 CI/CD等都有整体规划上的考虑。
本文方案采用 Karmada 作为多云管理的控制平面，具备以下优势：
Karmada 以类 K8S 的形式部署，它有 API Server、Controller Manager等，对已经拥有存量多 K8S 集群的企业来说，改造成本比较小，只需在上面部署一个管理集群即可；Karmada-Controller-Manager管理包括 cluster、 policy、binding、works 等多种 CRD 资源作为管理端资源对象，没有侵入到 K8S 原生资源对象；Karmada 仅管理资源在集群间的调度，子集群内分配高度自治。
Karmada 多集群管理架构
在资源调度方面，Karmada 可自定义跨集群调度策略，对上层应用透明，可按照集群标签或故障域自动分发资源对象；在集群管理方面，支持集群注册、全生命周期管理，有统一标准的 API。在资源管理方面，核心是支持 K8S 原生对象，支持子集群资源部署状态获取，资源对象分发既支持 pull 也支持 push 方式。
本文方案在 Karmada 上层架设云管平台，主要关注适配银行内部的系统、用户、应用、权限、基础资源资源管控相关能力，并融合 PaaS 层服务及应用商店等功能，也包括管理由 Karmada 衍生出来的 Policy（集群调度策略），整体架构如下：
基于 Karmada 的容器云管平台设计
4.1.3 Runtime 层改进降低故障率
容器云调度 Pod 从顶层到底层的调用关系是：编排引擎 API -> 容器 API-> 系统内核API， 目前K8S的主要调用方式是：KubernetesMaster -> Kubelet -> DockerEngine -> Containerd -> runc -> Linux Kernel。
K8S 容器运行管理组件演进
一是调用链其实相对复杂且 Docker 引擎本身偏重，二是 Docker 引擎的开发较慢，无法跟上 Kubernetes 的步伐，三是 docker 守护进程有单点故障，即docker 守护进程挂掉、升级、或出现安全问题时可能对主机上所有容器产出影响，这点也是最为重要的。
Docker 引擎容器管理调用关系
Kubernetes 在 1.20 版本已弃用 docker 作为容器运行时，采用 KubernetesMaster -> Kubelet -> CRI-containerd -> containerd -> runc -> Linux kernel 模式；红帽 OpenShift4 采用 Kubernetes Master -> Kubelet-> CRI-O -> runc ->Linux kernel 模式，两者都在一定程度上消除 Docker 引擎带来了弊端。
对于 k8s 的终端用户来说， 这仅是一个后端容器运行时的更改， 从使用方面来说几乎感觉不到任何区别；对于应用开发/运维人员来说，依旧可以继续使用Docker 来构建镜像，以相同的方式将镜像推送到 Registry，并将这些镜像部署到 K8S 环境中；对于 K8S 集群管理员来说，只需要将 Docker 切换成其它的容器运行时（比如 Containerd），并将节点容器管理客户端从 docker CLI 切换到crictl 或 podman 即可；且 Podman 不需要守护程序，利用用户命名空间模拟容器中的 root，Podman 还不需要接入具有 root 权限的 socket，进一步提升运维操作的安全性。
4.2 高性能云原生存储方案
单一的存储方式无法满足复杂的业务场景， 本文方案根据不同的场景内容提供对应的存储介质。
上云业务多场景存储方案设计
4.2.1 场景一：基于支持 CSI 的分布式 NAS 支撑上云业务的文件存储需求
对于支持多容器副本共享持久化数据的场景，一般可通过 NFS 文件存储满足相关场景；本文方案针对银行业务对存储高可用、高性能的需求，采用分布式 NAS 存储作为文件存储支撑该场景。
分布式 NAS 文件存储扩展特性
与传统 NAS 相比，分布式 NAS 具有更高性能和扩展能力，并可通过通过横向扩展，性能实现线性增长，也能利用纵向扩展解决容量需求。数据可分片、自动均衡实现更强的高可用性，可为各存储池配置不同的保护层级，增加存储空间使用率。
并结合存储设备提供的 CSI 插件实现 PV 的动态供给，实现更高效的管理。
4.2.2 场景二：基于 Longhorn 支撑上云业务的块存储需求
对于容器部署的业务有较高 IO 性能要求，且多个实例间不需要进行数据共享的场景， 一般可采用块存储支撑相关需求；本文方案采用 Longhorn 搭建分布式块存储。
Longhorn 是一个开源的轻量级可靠且功能强大的 Kubernetes 分布式块存储系统。其架构整体分数据平面(data plane)和控制平面(control plane)两层。Longhorn Engine 是存储控制器对应数据平面，Longhorn Manager 对应控制平面。
Longhorn 整体架构
Longhorn 将本地磁盘或安装在计算或专用存储主机中的网络存储形成共享资源池， 容器实际上基于宿主机存储进行 IO， 几乎性能无损。可以指定 volume 的大小、IOPS 的需求，以及需要跨主机的同步 replica 的数量（实现数据高可用）。Longhorn 会监测每一个 replica 的健康状况，对问题进行维修，并在必要时重新生成 replica。还支持为每个 volume 创建多达 254 个快照，这些快照可以逐个备份到 NFS 或 S3 兼容的辅助存储中。
在数据高可用实现上，Longhorn Engine 始终与其使用 Volume 的 Pod 在同一节点上，它跨存储在多个节点上的多个副本同步复制卷；同时数据的多路径保证 Longhorn Volume 的 HA，单个副本或者 Engine 出现问题不会影响到所有副本或 Pod 对 Volume 的访问；每个卷都有自己的控制器，所以每个卷的控制器和副本实例也可以升级，而不会导致 IO 操作明显中断。
4.2.3 场景三：基于 MinIO 支撑上云业务的对象存储需求
对于容器云上使用对象存储的业务，本文方案采用 MinIO 作为企业级对象存储方案。MinIO 基于 Apache License v2.0 开源，完全兼容 S3 接口，可搭建高可靠的集群，具备灵活的扩展能力以及超高的性能，支持积木式扩展，可建立众多的中小规模、 易管理的集群， 支持跨数据中心将多个集群聚合成超大资源池。
MinIO 存储系统的后端可以是磁盘， 也可以作为云网关， 对接第三方的 NAS 系统、 分布式文件系统或公有云存储资源，并为业务系统转换提供标准的对象访问接口。
另外 MinIO 是符合软件定义存储 SDS 理念的，兼容主流 X86 服务器以及ARM/飞腾平台，同时也可以移植到诸如申威（Alpha 架构）和龙芯（Mips 架构）等硬件平台，对于银行在信创方面探索有一定的参考意义。
4.3 金融级云原生网络方案
在银行进行容器云建设和应用上云，网络一直是难点和关键点，本文作者认为主要是以下三点关切：
主流的 K8S 网络方案与数据中心的传统网络架构很难融合，容器网络管理不透明。
多集群环境下，不同业务系统间细粒度的网络管控较难实现。
随着业务系统分布式、微服务转型，应用多活部署，跨集群微服务治理相对困难。
本文方案将通过设计 Overlay/Underlay 双栈容器网络打通容器云与传统 IaaS 层网络， 使得网络管控更具一致性；并建设高性能全局负载， 满足银行业务系统多活部署需求。
容器云网络整体设计
4.3.1 基于 Kube-OVN 搭建 Overlay/Underlay 双栈容器网络
Kube-OVN 是一个由国内公司开源的 K8S CNI 网络插件，本文方案基于Kube-OVN 作为容器集群网络解决方案，可较好解决上述关切问题。
选用 Kube-OVN 的核心优势如下。方案社区化且可扩展性强，利用社区最为成熟的 OVS 作为网络底座，复用 OVS 社区生态，基于 K8S 架构原生设计。可在容器集群兼容 Overlay/Underlay 两种网络， Overlay 和物理网络保持独立，可进行每个 Namespace 独立网络控制，具备分布式网关/集中式网关/NAT 控制的网络出口控制方式；Underlay 网络和物理网络直接打通，直连底层结构实现高性能，且支持 Pod 运行在不通 VLAN 中，通过 VLAN 实现网络管控，通过annotation 可固定 Pod 的 IP/MAC。
Kube-OVN 双栈容器网络架构
另外， OVS 层容器流量可全镜像， 便于安全审计， 流量分析；支持动态 QoS 限制双向带宽，流表实现 Service 避免 Iptables 性能损耗。
通过 OVS 做流量全镜像
基于上述方案， 非核心业务容器可基于 Overlay 网络部署， 节约网络资源，灵活易扩展，关键业务系统容器可采用 Underlay 网络模式，无缝融合数据中心网络管控；Underlay 模式天然实现多集群间 Pod、虚机、物理机网络打通，高性能满足多集群微服务治理需求。
4.3.2 全局高性能负载均衡
面对多容器集群的环境和应用多活部署的需求， 高性能的全局负载也是基础设施支撑在重要环节，本文方案设计基于 DPVS 建设全局高性能 4 层负载，基于 BFE Ingress Controller 作为各集群 7 层负载。
该方案在功能上可支持最小连接、轮询等多种负载均衡算法，支持 TCP、UDP、HTTP、HTTPs、FTP 多种业务场景，支持会话保持功能、流制等能力；基于软件方案在对接监控体系上有较好的可扩展性。
全局负载方案架构
在高可用设计方面，4 层负载使用 ECMP 等价路由实现 4 层的多活架构：负载均衡的配置每个实例都相同，互相备份。
集群入口采用百度开源的 BFE Ingress Controller。该 Ingress controller具备 Kubernetes 原生 Ingress 的功能， 并基于百度 BFE 的能力， 扩展了路由规则描述能力和服务间的流量调度能力， 支持根据 Host、 Path、 Header、 Cookie对请求进行路由、支持 Path 的精确匹配、前缀匹配，支持 Host 的精确匹配、通配符匹配，多 Service 之间负载均衡，支持在提供相同服务的多个 Service 之间按权重进行负载均衡，支持基于 HTTP Header/Cookie 的服务灰度发布。
4.4 高可用及容灾设计
4.4.1 整体设计
容器云平台的高可用可以分为单集群高可用方案、单个机房高可用方案、多机房/多地高可用方案和应用高可用方案
4.4.2 单集群高可用设计
计算层：一个机房内单个 K8S 集群内的 Master 节点、Node 节点均位于不同机架；
网络层：各层级网络设备均备份冗余，存储流量、管理流量、业务流量使用不同的网卡进行分离；
存储层：分布式 NAS 存储分不同机架放置；物理机块存储或存储设备底层均使用 Raid 10，实现磁盘故障冗余。
4.4.3 容器云平台单机房高可用方案
考虑到容器云集群可能会出现系统性风险， 容器云平台在单个机房内的高可用方案可考虑采用多集群方案，即部署多个相同集群，关键应用在多个集群上都部署并可以根据运行情况，灵活切换流量，当一个集群出现问题时，流量可切换到其他集群。
4.4.4 容器云平台多机房/多地容灾设计
为应对极端机房级故障情况，使整个容器云平台具备快速容灾能力，控制平面 Karmada 集群需具备多数据中心快速容灾能力。为使得容器云管控制平台达到金融级的可用性，本文方案为控制平台集群设计了 Etcd 多机房容灾方案。
Etcd 多机房容灾策略主要有以下几种：
一是单集群多地部署，不同节点部署在各地机房，跨城部署网络之间质量也较容易波动，易导致服务质量抖动，client 访问 Etcd 集群的配置，须配置多个Etcd 节点，可能导致 client 访问到异地的 Etcd 节点，导致服务请求延时增大。
二是 make-mirror 方案，在不同机房部署独立的 Etcd 集群，通过 make-mirror 工具实现跨城数据复制。主 Etcd 集群读写性能高， 整体上不受跨地域网络延时、网络质量波动影响；但当写请求较大的时候，备集群可能存在一定的数据落后， 可能读到脏数据；make-mirror 同步链路中断后， 退出重启会进入全同步模式，无法满足生产环境性能诉求；同时缺少 leader 选举、数据一致性检测、日志、Metrics 等一系列特性，不具备生产环境可用性。
三是社区的 learner 方案，Etcd 社区在 2019.8 月推出的 3.4 版本中，正式支持 Learner 节点，它作为非投票（Non-Voting）的成员节点加入集群，不参与集群选举等投票，只进行数据复制。Leader 收到写请求后，将日志同步给Follower 和 Learner 节点， 并在内存中使用一个名为 Progress 的数据结构， 维护 Follower 和 Learner 节点的日志同步进展信息。当 Learner 节点的数据与Leader 数据差距较小的时候，它就可以被提升为可投票的成员节点加入集群。
Etcd 的 learner 容灾方案
但 Learner 节点只允许串行读，也就是业务如果就近读，会读到旧数据；且依赖高版本 Etcd，Etcd 3.4 及以上版本才支持 Learner 特性，并且只允许一个Learner 节点；主集群全面故障后，无法快速将 Learner 节点提升为可写的独立 Etcd 集群。
为了解决 make-mirror 的各种缺陷，etcd-syncer 的 mirror-plus 方案实现了以下特性、优点：
支持多种同步模式，全量同步、断点续传，不再担忧专线、公网网络质量抖动；
高可用， 负责同一数据路径复制的实例支持多副本部署， 一副本故障后，其他副本将在 5 秒后获得锁，在之前实例同步的进度基础上，进行快速恢复；
支持一致性检查（全量数据检查、快照检查）；
支持多实例并发复制提升性能（不同实例负责不同的路径），可生产环境配置多实例，每个实例负责不同路径；
良好的运维能力， 基于 K8S Deployment 一键部署， 丰富的 Metrics、日志，完备的 e2e 测试用例覆盖核心场景（http/https 场景，服务异常中断、网络异常等）；
但它核心原理依然是依赖 Etcd 的 mvcc+watch 特性，因此数据无法保证强一致性和只同步 key-value 数据；断点续传依赖 mvcc 历史版本保留时间， 当写请求较大的时候，备集群可能存在一定的数据落后，可能读到脏数据，统一不支持同步非 key-value 数据，如 auth 鉴权相关数据、lease 数据等。
为解决所有类型的数据同步问题以及消除对 etcd mvcc 历史数据的依赖，本文方案参考业界基于 Raft 日志的 Etcd 同步方案，etcd-syncer 同步服务作为一个类似 Learner 节点的身份，加入主集群，其的部署图如下所示：
基于 Raft 的 Etcd 同步方案
主 Etcd 集群 Leader 将 Raft 日志数据通过 MsgApp/Snapshot 等消息同步给 etcd-syncer，etcd-syncer 解析 Raft 日志，将 Raft 日志条目对应的Txn/Delete/Auth 等请求应用到备份 Etcd 集群。该方案具备 etcd-syncer 的 mirror-plus 版本的所有特性和优点，同时不依赖 etcd mvcc 历史数据；基于Etcd 底层的 Raft 日志同步数据，可以同步 key-value、auth、lease 等各种类型的数据，且不依赖高版本 Etcd。
4.4.5 上云应用高可用设计
单集群高可用：服务化的应用在单个 K8S 集群至少部署 2 个副本；
多集群设计：基于容器云管平台定制的部署策略，每个应用默认至少部署至单 AZ 内 2 个 K8S 集群上，预防集群级故障或集群级维护的风险；
多机房/多地高可用集群：基于控制平面 Karmada 的能力，对应用默认进行跨集群故障恢复；
系统高可用设计：对于数据层具备跨机房恢复能力的系统，通过控制平面默认进行多机房 K8S 集群上的应用部署；控制平面及企业级制品库保存应用全量编排及镜像信息，数据层根据不同系统安全等级进行实时或准实时复制，可基于控制平面实现分钟级的在异地进行应用容灾。
5 通过 PaaS 层能力为研发提供统一技术服务
5.1 基于容器云资源池提供中间件 PaaS 服务
5.1.1 提供常用 PAAS 化服务
为了统一管理基础架构软件， 本文方案基于云基础设施建立统一的基础技术平台。通过该平台，在满足银行的技术收敛性要求和安全性要求下，为研发人员更加便捷地提供开源中间件组件。通过该平台提供开放的应用市场，统一管理云上的中间件模板、应用模板，大幅较低研发团队重复造轮子的工作。
对研发常用技术进行 PaaS 化，项目组可以像使用水、电一样按需使用相关技术服务；将常用的缓存中间件、消息中间件、代理组件等开源软件 PaaS 化，可大幅提升基础技术获得的效率， 集约化资源使用， 统一提供高可用、 弹性伸缩、监控；有利于推进专业化分工， 也有利于提升系统研发速度、 运行性能和稳定性。
通过 PaaS 服务统一支撑业务系统需求
5.1.2 基础技术平台设计
基础技术平台服务底层基于 Operator 技术和 Helm Chart 来提供统一的中间件服务的部署和管理，在云基础设施上建立 PaaS 化服务；并基于技术准入标准目录， 对整个银行系统信息管理需要使用的基础中间件进行统一的引入、 审核、改造、部署并提供统一的安全补丁管理。
基础技术平台整体设计
本文方案设计的基础技术平台整体架构如上图所示，有以下核心模块：
基础技术平台管理门户：整个基础技术平台管理门户对下管理各个容器云集群的 Operator 管理器和 elm 管理器，提供统一的中间件 PaaS 服务管理能力；对上提供中间件服务的上架、扫描、更新，并使用制品库管理镜像、Operator Package、Helm Chart 包；
Operator 管理器：基于 Redhat 开源的 OLM 框架，统一安装、更新、管理所有 Operator 以及容器云集群中运行的关联服务的生命周期；
Chart 管理器：Chart 管理器基于原生 Helm chart 的语法进行增强，引入 ksonnet 定义统一的云原生原语， 并基于 Operator 重新实现原有Helm chart 命令行的能力；
中间件服务管理器：复杂中间件基于 Operator-sdk 实现，选择其稳定开源版本，对其安全性、稳定性进行增强，提供高可用 PaaS 服务；一些简单的中间件应用（如 Activemq、Eureka、注册中心），则采用基于 ksonnet 重写 Helm chart，通过 Chart 管理器进行统一的生命周期管理。
基础技术平台提供常用的开源中间件服务
5.1.3 Operator 管理器设计
Operator 管理器定义了标准的 Operator 的 CRD 资源和接口，同时Operator 定义的 CRD 资源也需要实现标准的服务管理资源。通过统一资源和接口，Operator 管理器可以统一管理中间件 Operator 的生命周期。
Operator 管理器原理
对云基础设施进行抽象，统一了底层能力的使用。当开发一个中间件的 Operator 需要使用存储、网络、监控、日志等功能时，根据场景选择基础服务按照规范接入即可：
存储：基础技术平台使用云基础设施的存储组件进行数据的持久化，对于 IO 要求较高的中间件服务（如 Kafka、ES、Redis）采用 Loghorn提供块存储；对 IO 无特殊要求的服务 （如 Eureka、 ActiveMQ、 Nginx）采用分布式 NAS 文件存储进行数据持久化；
网络：基础技术平台中的中间件组件使用云基础设施的网络能力，通过四层 LB 提供统一的外部访问能力，通过 Kube-OVN 提供的 Underlay能力打通各个容器集群网络，实现中间件服务的多活和灾备；
日志采集：基础技术平台对接云基础设施提供的日志平台，统一管理各个基础服务的日志，统一进行日志预警；
日志平台基于 ES alert 实现日志告警
监控告警：基础技术平台对接云基础设施的监控 API，调用容器云平台 API 配置各个中间件使用的 Servicemonitor、 Prometheus rules 完成监控接入统一监控中心，同时基础技术平台对接监控中心的监控展示 API，提供通用的Grafana.json 接入统一监控系统。
5.1.4 Chart 管理器设计
Chart 管理器实现 Helm chart 的全生命周期管理， 通过 CRD 实现来 Helm chart 的功能， 除支持开源 Helm chart 外还提供增强功能的 Helm chart 语法，基于 ksonnet 可以实现复杂编排、编排依赖、引用等高阶功能。
Ksonnet 原理
此外 Chart 管理器还实现了通用应用的运维和故障自愈 CRD，使用 Chart模式上架的基础技术服务可以通过 CRD 提供基础的起停、运维能力，并集成到基础技术平台门户。
5.1.5 安全合规交付与统一服务升级
金融行业对于技术的安全性和高可用要求是极高的，开源中间件从选型、 引入到改造、上线，必须满足金融业的监管要求。
根据信通院开源生态白皮书的推荐分类根据银行的业务需求， 基础技术平台将引入的开源中间件分为以下类型：
消息处理中间件：负责跨系统的数据传递、高并发的流量削峰、数据异步处理，如 Kafka、RabbitMQ；
事务处理中间件：提供全局事务服务，用于解决分布式环境下的事务一致性问题，提供支持跨数据库、跨服务以及混合分布式事务接入服务；
缓存中间件：提供高性能内存数据库，提供 K-V 数据结构的数据存储，满足系统高并发及数据快速访问的需求；
Web 服务中间件：提供静态 Web 服务的能力，提供静态 html 页面、文件、音频、视频存储和访问；
网络代理中间件：处理系统内的网络路由、 反向代理， 如 Nginx、 Apache等服务，传统服务常会使用；
搜索中间件：提供全文检索的能力，如 ES；
开发框架服务：根据各类语言开发框架定制化开发的应用组件，详情请见 5.5。
本文方案基础技术平台会对每个引入的开源软件进行技术目录校验、 制品库安全扫描、安全补丁跟踪，当开源中间件有新的安全补丁发布或不再维护声明发布时，平台会通知中间件负责人员，并生成对应需求。
本文方案基础技术平台同时提供一整套中间件升级的流程，升级分为两类：
中间件补丁升级：中间件在小版本的安全补丁基本对上层应用使用兼容，只需要更新其标准镜像即可完成补丁升级，整个升级流程如下：
中间件安全补丁升级流程
5.2 多云异构微服务治理
传统的企业架构中，单体应用大多通过采用企业服务总线（Enterprise Service Bus， 简称 ESB） 和面向消息的中间件 （Message-Oriented Middleware，简称 MOM）来进行服务治理。云原生体系下，将业务微服务化才能更好发挥基础设施效能，但是银行复杂的业务场景，所有业务系统全面进行微服务重构存在风险， 部分业务可能已经进行微服务改造部分还未进行，同时各类型系统技术栈不同，可能基于不同的微服务框架建设。为解决上述问题，本文方案建设统一微服务治理平台，提供统一的分布式运行时，将传统单体应用和微服务应用统一管理，基于云基础设施统一提供上云应用的追踪、治理的能力。
5.2.1 微服务治理平台整体设计
微服务治理平台在每个容器云集群部署一套完整的微服务运行时， 由统一的微服务治理平台提供统一的服务治理能力，本文方案基于 Dapr 和 Istio 框架，开发了统一的微服务运行时， 传统应用通过 Istio 接入到微服务框架中， JAVA 微服务通过 Dapr 解耦微服务框架（Dubbo、SpringCloud），通过 Dapr SDK 进行微服务治理。
微服务治理平台整体设计
整个平台分为以下部分：
底层设施服务，引用已有的容器云基础设施提供监控、日志和制品库；
Istio 运行时，提供基于 ServiceMesh 的服务治理，用于治理传统单体应用，提供服务注册发现、配置管理、服务路由管理等治理能力，对接底层设施服务提供 APM、监控的能力；
Dapr 运行时，提供抽象微服务原语，提供可插拔的抽象
微服务组件，提供微服务治理能力，提供注册发现、配置管理、服务路由管理等治理能力，提供 APM 和监控的能力；
微服务同步组件：同步 JAVA 微服务和 Istio 中注册的服务，提供统一的服务注册中心；
多集群同步组件：提供跨集群的服务治理能力。
5.2.2 统一微服务注册治理设计
银行业务中传统单体应用中可能占绝大部分， 如果将其重构为微服务架构整体工作量较大且有相当大的风险；已有的 Springcloud 和 Dubbo 类的微服务也占比较多，如使用 Istio 改造 JAVA 微服务同样有架构变更的阻力，如果通过 Istio 注册服务和 JAVA 微服务框架可以统一注册、统一发现，使用一套框架镜像治理，上述的问题就可以得到解决。本文设计方案基于统一的微服务运行时平台，来打通两个框架（Istio、JAVA 微服务）的服务治理功能，提供统一的微服务运行时。
统一微服务运行时平台设计
整个微服务运行时平台由以下核心组件构成：
JAVA 微服务服务组件：
➢ 注册中心、配置中心：为微服务提供服务注册发现、配置管理，服务元数据管理的能力；
➢ 微服务网关：为微服务提供统一的认证鉴权、 负载均衡、 限流熔断的服务路由能力。
Istio 组件：
➢ Istio 控制平面：基于 Istio 实现， 控制平面负责统一管理整个容器云集群的微服务配置， 提供服务安全配置、 服务负载配置、 服务路由配置、 服务流量治理撇脂以及分布式链路配置；除Istio原生的功能外，Istio 控制平面还提供应用配置的统一管理、应用日志采集的统一配置管理；
➢ Istio 网络代理：基于 Enovy 实现，构建应用间的通信平面；Istio 代理拦截来所有进入容器和流出容器的请求，根据控制平面的服务治理配置， 完成容器的服务鉴权、 流量管理、 数据链路追踪以及服务流量的治理功能；
➢ Istio 文件代理：文件代理服务管理单体应用中的配置、日志采集、调试组件等功能，容器应用时自动注入 Sidecar，获取控制平面的配置信息，提供应用的配置文件管理、日志采集管理能力。
微服务同步组件：
➢ 微服务同步组件：定义统一服务语义，同步注册中心和 Istio 中注册的服务，提供注册同步、统一发现的功能；微服务通过 SDK 注册服务的时候，同步组件根据注册事件向 Istio 中同步写入注册服务、健康检查等信息；Istio 创建应用时， 同步组件根据容器云 Etcd 中注册的服务数据向注册中心中注册服务、健康检查等信息；
➢ 微服务运行时组件：定义统一的微服务治理的语义，通过调用 JAVA 微服务的 API 和调用 k8s API 创建 Istio 治理相关的 CRD，统一提供一套通用的服务治理的能力，提供给微服务治理门户；
➢ 多集群微服务管理组件：负责处理跨集群微服务的同步、 治理；银行容器云基础设施由于监管要求和高可用要求， 部署于多网络区， 跨网络区的服务访问是相互隔离的，需要申请单独的网络防火墙开通才可以访问；整个管理配置通过微服务治理门户进行同步， 跨网络区的服务访问通过容器云 Kube-OVN 提供的高性能 Underlay 网络能力打通。
5.2.3 可插拔微服务运行时设计
微服务架构在发展过程中主流框架迭代更新速度非常快， 微服务治理平台作为底座又需要保持其稳定性、可扩展性，微服务框架更新导致的 SDK 不兼容对于银行业务是一个极大的风险。本文方案提出了基于 Dapr 框架的统一标准，可配置的微服务运行时，基于微服务治理平台，通过可插拔的方式就可以更新注册中心、 配置中心、 APM、 日志采集， 而无需修改业务代码， 大大增加了可扩展性。方案抽象了以下微服务的基础能力：服务调用能力、状态管理能力、订阅发布能力、并发能力、资源绑定能力、可观测性能力、密钥管理能力：
下图通过服务注册和发现的例子说明 Dapr 运行时的核心理念：通过标准化原语 SDK 和运行时 SideCar 实现可插拔的微服务运行时：
Dapr 原理
本文方案设计了基于 Dapr API 提供了服务注册发现、服务配置、服务链路接入的标准 SDK。应用使用 DaprSDK 接入，调用标准的微服务原语，应用不需要需要在代码代码里引入注册中心、配置中心、APM 的 SDK，也不用关心实际微服务框架是什么、使用是什么通信协议，业务代码只需要调用 Dapr SDK，使用分布式原语和 Dapr Runtime 通信，Dapr sidecar 决定具体的微服务框架使用。
6 云原生体系下的安全合规交付体系设计
6.1 云原生交付体系整体设计
“基建”层在高可用、高性能上提供了多样化的能力，PaaS 层提供了上云业务的统一日志、监控告警、基础技术服务和服务治理能力；为实现业务上云全生命周期，安全合规且高效的交付体系也是重要一环，本文方案设计的交付体系分以下三个核心部分：
DevSecOps 实践安全合规交付：本文方案结合 DevOps 工具链和安全扫描工具实现交付自动化安全合规审查， 打造自动化交付平台为应用上云安全合规交付保驾护航。
一键对接应用开发平台/框架：云原生技术栈对于研发、运维人员存在一定的学习成本，本文方案设计云原生应用开发平台与下层服务整合，帮助银行内自研类业务，从研发即云原生，一键实现代码容器化改造、微服务接入、中间件使用；
企业级制品库作为交付中枢：本文按方案采用统一的制品库来管理研发侧和生产侧的制品；整个制品库采用高可用架构设计， 提供了各类型制品的存取、流转、 安全扫描的能力；作为 CI/CD 流水线中枢， 是交付体系的核心基础设施。
6.2 DevSecOps 实践安全合规交付
通过云原生应用平台/框架、制品库和流水线，可将应用上云的构建、发布串联起来，结合基建层和 PaaS 层的能力，可便捷实现服务治理、使用中间件服务，目前整个 DevOps 工具链以及方法已经相对比较成熟，各个企业已可便捷借助开源、 社区等力量构建符合企业自身需要的工程流水线， 通常一个 DevOps 平台及工具链的组成如下所示，因整体体系较为成熟，本问方案对 DevOps 本身不再进行详述。
DevOps 体系
银行业因监管要求对于交付的安全合规由要求，因此 DevOps 需要和安全结合在一起，DevSecOps 也应运而生。本文方案设计的云原生自动化交付平台基于 DevSecOps 和银行监管的安全合规要求，承载了应用从需求、开发、测试到上线、更新、运维的全生命周期，并将安全任务注入其中。
6.2.1 DevOps+安全合规
DevSecOps 的核心是在 DevOps 流程中引入了安全流程， 本文方案在应用上云的全流程中引入了分析、安全、验证、防御、文档五个流程：
分析：根据不同的环节识别不同的关键安全问题，修复每一个阶段的安全风险；研发团队的安全任务为代码安全规范、静态扫描；测试团队的安全任务渗透性扫描；运维团队的安全任务为云基础设施的安全漏洞扫描；
安全：在分析出安全漏洞后，立即提供修复策略，并在 CI/CD 流程中标注，直到完成修复进行一次全量构建；
验证：验证流程会在 CI/CD 流程后进行自动化安全测试， 并随着分析流程推进逐步更新；
防御：在生产环境检测攻击和防御漏洞， 在 DevOps 的部署介质中定义自我保护服务，承载防御能力；
文档：逐步完善企业知识库，预防同样的问题。
DevSecOps 流程
DevOps 的理念中，参与者是不可或缺的一环，在整个 DevSecOps 流程制定后，还需要一系列的 DevOps 活动才能够更好更快的在 DevOps 流程融入安全，通过这些活动明确不同团队的职责、完善安全流程，确保安全合规交付：
赋权工程团队：制定安全规范和流程， 在开发、 运营、 运维团队中推广，并明确职责；
安全可视化：在 DevOps 全流程引入安全并进行可视化管理，在DevOps 看板中引入安全任务、在流水线中引入安全步骤；
安全左移：从需求开始引入安全活动，眼神到整个 SDLC，确保开发到生产每个阶段可以提供持续的安全反馈；
安全即代码：安全功能集成到开发、运营中；
持续安全：和持续构建的过程类似，在软件生命周期中持续的进行安全任务。
6.2.2 自动交付平台流程
工具和自动化是 DevOps 的核心，基于 DevSecOps 的流程和关键活动，本文方案将 DevOps 工具、安全工具、CI/CD 流程系统进行了统一整合，建设云原生自动交付平台。
自动交付平台安全审查流程设计
在整个系统研发周期中引入安全工具， 安全工具在软件开发周期中处理不同类型的安全问题，其中和本平台密切相关的步骤如下：
安全编码：针对不同 IDE 制定 checkstyle 模版，确保编码安全性；
IDE 安全工具：基于 Synopsys 分析引擎对不同框架的应用进行安全测试扫描；
源代码扫描：基于 Sonar 进行源代码扫描，与 DEV 环境流水线集成；
开源组件扫描：基于制品库 X-RAY 的介质镜像扫描，对接互联网安全库，定时检测基础技术平台和微服务治理平台的安全漏洞；
安全扫描：基于商业安全工具的扫描工具，与 UAT 环境流水线集成；
自动交付平台安全合规扫描
安全合规评审：整个开发过程中的安全扫描结果和构建流程基于漏洞个数，修复比例，流水线使用率进行安全评分，安全团队针对安全评分和安全扫描结果判断是否该项目符合上线安全规范。
本文方案将上述安全合规审查工作自动编排， 实现交付自动化安全合规审查。
6.3 应用开发平台/框架实现一键云原生改造
基建层和 PaaS 层提供了微服务运行时和统一中间件服务，应用项目组只需要专注于业务需求开发即可， 但对容器技术没接触或接触少的研发团队仍然会面临新技术的学习成本高、改造难度大等问题。为了解决这个问题，本文方案设计基于云原生技术体系的应用开发平台，屏蔽云原生的技术复杂度，让各业务快速完成上云。
6.3.1 应用开发平台/框架整体设计
开发平台主要为了解决项目组开发应用后如何上云，并在此基础上对接 Devops 进行多环境发布、生产发布，基于银行系统的特性，我们将应用分为以下两类：
第一类应用是基于银行标准的开发框架开发的，这类应用基于银行内部体系化的开发框架开发，架构比较确定，可以通过改造将修改点剥离，形成较为固定的应用镜像和编排文件，将变量最小化，实现简单配置即可上云；
第二类应用一般是创新的项目或者合作开发的项目，这类项目并不会使用标准的开发框架开发， 这类应用一般会使用 JAVA 微服务这类开源的框架进行开发，开发的架构多种多样；针对于这类应用，通过开发平台把云上的部署进行抽象，并实现表单化、图形化，项目组在应用开发完成后，即可通过流水线一键部署。
一键云原生应用开发框架整体设计
开发平台/框架整体架构如下：
开发平台门户和 IDE 插件作为应用开发的入口，可以通过 IDE 提交项目元数据也可以通过 web 页面配置；
标准框架开发平台，底层针对每类开发框架实现了一个 Operator，Operator 基于基础技术平台的 OLM 框架实现，将所有的部署配置抽象剥离，标准框架开发平台再将这些 CRD 和关联系统融合（微服务环境地址补全、中间件访问环境地址补全、Devops 流水线对接），去掉可以自动补全的服务配置，将最小化的配置形成 API 提供给 IDE 和门户调用，完成一键上云部署；
通用应用开发平台，基于基础开发平台的 Chart 管理器，将 ksonnet 的原语进行来图形化的映射，并抽象了上云应用的服务概念；平台将 K8S 中的某一个资源抽象成可配置的模版 （如 service 端口、 deployment 的暴露端口等） ，并定义了一个应用的组成部分，最后把服务间依赖引入，最终实现图形化的通用开发平台。
6.3.2 标准框架应用开发平台设计
标准框架应用开发平台将整个应用分解成以下模块，将关联系统融合到一起：
标准框架应用开发平台设计
微服务注入模块：微服务框架服务配置抽象为模版， 单体应用将 Istio 的 CRD 资源抽象，微服务框架将微服务组件抽象，实现多环境替换；
基础中间件注入模块：根据标准中间件 Client，将中间件配置抽象，实现多环境替换；
流水线模块：对接不通开发框架定制单独的 CI/CD 流程；
Operator 管理模块：对接微服务注入、基础中间件注入模块，构建不同框架的 CRD 资源完成应用的直接部署；同时也对接了流水线和自动化安全工具，提供多环境构建和升级；
IDE 模块：对接不同 IDE（VScode、IDEA）和 git 仓库，提供本地服务一键上云。
6.3.3 通用应用开发平台设计
通用应用开发框架基于基础技术平台的 Chart 管理器实现，将上云应用抽象为实例、 微服务、 容器、 服务、 配置文件， 并提供表单图形化的页面开发平台：
通用应用开发平台设计
通过开发平台完成应用云原生改造的可对接 PaaS 层提供了 Operator 和Charts 管理器，实现应用商店功能。
6.4 企业级制品库作为交付中枢
6.4.1 制品库建设方案
DevOps 可以提升开发和运维团队间的协作，并且通过自动化和可重复的方式将代码更快地部署到生产。有助于加快组织交付应用和服务的速度。对产品交付、测试、功能开发和维护起到了意义深远的影响。项目组在开发过程中引用着越来越多的组件，研发效率上去了，但是随着我们依赖组件越多，引入漏洞的风险也越高，通过人工发现的依赖漏洞变的更加艰难，因为漏洞藏的越深，修复漏洞所花费的时间就越长。因此，对于制品的管理（版本管理、风险管理）尤为重要。
作为企业 DevOps 流水线的枢纽，本文方案采用 Jfog Artifactory 建设企业级制品仓库， 可较好的满足银行对于软件制品管理的需求。制品库作为中转站，将构建与部署之间的耦合度降到最低，可大幅度提升协作效率。通过制品库的支撑，可较好达到工具贯通、流程优化、规范建设的效果。
制品库作为研发测交付体系中枢
本文方案制品库搭建按银行网络管理要求，在研发侧、生产侧分别建设。
制品库建设方案
在研发侧和生产侧的制品仓库管理上， 继承传统软件介质管理和流转的策略，做到流程和管理上的合规：
研发测制品库管理策略
生产测制品库管理策略
6.4.2 制品流转设计
在制品库使用方面，为各系统设计开发库、测试库、待投产库和投产库。项目组由开发库逐步晋级至测试库、待投产库，最终晋级至投产部署生产。
制品流传策略
开发阶段的 CI 流程完成镜像制作成功后，将镜像及镜像信息推送至制品库镜像库中的开发库；应用系统随部署环境的不同需要准备不同的部署脚本 （yaml文件），并将 yaml 文件上传到制品库的开发库中。
测试阶段可以定义流水线的准入准出、制品晋级、测试部署等流程：
准入准出
首先需要关联 CI/CD 流水线，以保证该流水线的输入为对应的持续集成CI/CD 流水线的输出（制品）。测试准入完成后，对制品晋级。
制品晋级
将镜像从开发库晋级到测试仓库形成 SIT 版本；将 SIT、UAT、PRD 三个环境部署脚本、Yaml 文件从开发库晋级到测试仓库。
测试部署
对接容器云平台，拉取制品库对应的制品和 yaml 文杰，应用自动部署至容器云上。之后进行一系列 ATP 测试、性能测试、手工测试，测试完成后，测试准出，该流水线执行完毕。
预发布阶段， 可以定义预投产阶段的准入准出、 制品晋级、 测试部署等流程，部署流水线和预发布流水线， 这两条流水线包含的过程一样， 差别在于晋级仓库、部署环境、测试内容等。该流水线在待投产环境中部署，并进行相应的 ATP 测试，测试完成后，测试准出。
最终制品在通过 X-Ray 扫描后晋级至投产库。
6.4.3 生产制品库高可用部署设计
本文方案中制品库作为生产容器云平台的镜像仓库， 其高可用性也尤为关键，关系到上云应用自愈漂移、部署调度相关能力。以银行的两地三中心及多 AZ 为例，本文设计的制品库建设方案如下：
生产环境制品库高可用部署方案
各中心建设高可用 Artifactory 制品库，制品存储对接 MinIO 对象存储，各中心之间制品和数据库进行实时同步。为了提高镜像的下载速度，以加快应用的部署，镜像服务还开启 P2P 预热，生产中将应用镜像提前分发到 P2P 网络。基于此方案，可支撑应用一键快速发布至各中心容器集群。
7 云原生运营监控手段
7.1 运维体系整体设计
全面云化对运维体系提出了更高的要求， 本文方案设计的运维体系整体架构如下：
运维体系架构图
统一 CMDB 为运维侧所有系统和平台提供统一的配置基准数据；自动化运维平台自动采集和发现价值数据和数据关联，实现云平台资源管理、伸缩、应用下发、部分故障处理的自动化；监控结合 CMDB 配置数据将详尽真实的告警详情告知相关负责人；运维大数据通过多样化、不同通道的方式，集成各系统和平台的实时或历史的结构化、非结构化数据，并进行过滤清洗、加工分析、输出和数据持久化；IT 架构可视化系统通过业务系统部署架构图、业务逻辑架构图、业务网络拓扑图三类架构图的形式，直观的展示业务系统整体运行状况；运维大数据中不同数据源的数据和 IT 架构可视话共同支撑 AIOPS 运维场景， 智能产出运维建议，实现智能告警和故障分析检测。
7.2 多云监控运营方案设计
本文方案设计的多云监控服务基于 Prometheus 套装建设。为了便于对多个集群集中监控，采用 Prometheus Federation 架构实现多级监控，将不同集群监控指标统一收集，并将历史监控数据持久化在 MinIO S3 存储中，通过 Grafana 展示图表。Prometheus 根据报警配置来计算报警信息并推送给AlertManager，由其去对告警除重、分组，再路由到对收的接受方式，发出报警。
多 AZ 的 Promethues 联邦
监控系统的 Promethues 逻辑上划分为三大层级。不同层级通过联邦的方式传递数据：
全局层：主要提供全局的视角，提供跨机房的信息汇聚能力。
联邦层：部署在各个机房，提供机房层的视角，提供跨网络域的信息汇聚能力。
采集层：部署在各个网络域，直接对接监控目标，提供实例级别的监控视角。
统一监控
通过监控门户即可查看监控页面， 并且通过页面上的连接即可下钻到各层级的监控页面，监控服务网关会动态路由到各节点。
全局告警设计
Prometheus 中定义告警规则(Rules)，向 AlertManager 发送告警，AlertManager 会对告警信息进行进一步处理，比如分组、抑制、静默。容器云平台通过 Webhook 接收到 AlertManager 处理后的告警信息，一方面会存库在门户页面展示，另一方面对接邮件、短信的形式发出。
统一告警
7.3 集中日志平台设计
本文方案日志平台整体技术方案基于主流的 ElasticSearch、Logstash、Filebeat、Kafka 建设。
采用轻量 Filebeat 来收集集群组件日志及应用标准输出的日志，支持以DaemonSet 和 sidecar 的形式通过 filebeat 收集日志文件（适用于不通的上云业务） ， 将其发送到 Kafka 中日志缓冲， 由 Logstash 处理转发到 ElasticSearch服务，最后由 Kibana 服务展示。
生产环节两地三中心网络域众多， 本文方案通过在各 AZ 部署日志服务基础组件提供各 AZ 的日志服务，该承载量较大，且可避免日志流量跨 AZ 造成防火墙压力。
集中日志平台设计
该日志方案可适配银行生产业务中的各种场景， 而且能够支持高并发日志量。同时各组件均可通过横向扩展来扩大整个日志平台的吞吐量。
集中日志检索
7.4 适配云环境的 CMDB 设计
云原生体系下 CMDB 与传统虚拟机部署服务 CMDB 有较大的不同，一方面不同于虚拟机应用部署于固定的服务器，Pod 所属的 Node 节点通常不是固定的，且 Pod 名和 IP 地址是随机分配的，这导致云原生系统的资源属性在运行过程中的变化是一种常态。因此本文方案的 CMDB 进行了适配的设计，将容器云的资源配置信息，纳入整个传统机房的管理，并实现信息的自动采集。
云原生系统资源多以 Namespace 为框架进行组织， 这提供了一个便利， 可根据 Namespace 内各类资源进行实时高频的信息自动采集，在实施云原生CMDB 信息管理的时候以 k8s API 进行信息采集。
本文方案针对云环境下的 CMDB 表设计参考如下：
云环境下的 CMDB 设计参考
7.5 基于 EBPF 增强可观测性
7.5.1 EBPF 技术实现无侵入式全指标监控
传统云上监控手段有指标监控、 APM应用性能监控和NPM网络旁路监控，在实现云上业务的监控全覆盖中存在局限性：指标监控如 Prometheus 可以提供主机和容器级别的内存、CPU、网络流量、磁盘读写和容量的统计性指标，但缺少链路追踪能力，无法对云上的复杂调用链路进行梳理分析，无法建立云上业务拓扑模型，缺乏业务故障分析和业务状态监控能力；APM 应用性能监控可以实现链路追踪，识别几个应用之间的业务调用关系，同时提供代码级的透明化性能分析，但 APM 需要对业务系统进行代码改造，侵入性明显，对可支持的应用系统架构和技术代码语言也有要求，在部署时需要应用重启，使用与升级时间成本大；NPM 网络旁路监控通过交换机端口镜像分析流量数据，识别业务关系，从而实现链路追踪的功能，但是在云化环境中交换机端口镜像存在限制，云上虚拟网络不经过物理交换机，使用 NPM 存在监控盲区。
EBPF 技术是当下最先进成熟的 Linux 内核技术，通过高级“内核虚拟机”可以在内核中运行沙盒程序，而无需改变内核源码或加载内核模块，具有高安全性。EBPF 内核技术为应用与系统内核打造了一座桥梁， 在系统安全、 网络优化、跟踪与性能分析、观测与监控等领域都发挥重要作用。这也是为什么基于 EBPF 技术的监控方案是对云上业务运维监控的革命性方案。基于EBPF技术做云监控，可做到无侵入，对用户态程序不用做任何修改；高性能；高可靠，内核编译器对EBPF 程序进行代码校验，保证 EBPF 程序的安全稳定。
容器云环境下 EBPF 监控程序运行形态
在一个节点上运行的所有容器（也就是所有的 Pod）共享同一个内核。如果你在内核中添加一个 EBPF 程序到一个事件中，它将被触发，无论哪个进程引起该事件，无论它是在应用容器中运行还是直接运行在主机上。只需要在每个节点部署，所有的应用程序 Pod 都会被覆盖。无论是做可观察性、安全性还是网络，由 EBPF 驱动的解决方案都可以在不需要 Sidecar 的情况下对云环境下的应用进行检测。
7.5.2 EBPF 监控系统架构设计
本文方案基于 EBPF 技术建设的监控平台整体架构设计如下，分为采集端，数仓和展示层，如下图所示：
EBPF 监控系统架构设计
采集端结合 CMDB 元数据和个服务器 EBPF 采集的内核信息加工处理为监控元数据， 数据处理层使用Flink做数据流处理， 后基于图数据库做指标持久化，用于做整体监控大盘展示。该监控系统可在网络层面进行服务上下游调用分析和节点观测， 在系统层做链路观测， 包括应用流量， TCP 链接等；可建立路由拓扑，关联路由数据，实现全链路观测；还可基于数据进行健康度分析，异常检测。
基于 EBPF 实现云原生应用全链路追踪
7.6 基于 AIOPS 的智能运维体系
7.6.1 AIOPS 平台整体设计
全面云化后使用 AIOPS 技术提升运维效率较适合大规模企业，本文方案设计的 AIOPS 平台架构如下：
AIOPS 平台设计
底层是数据源层， 提供各种运维数据库包括结构化数据如关系型数据库以及非结构化数据例如各种系统日志，这些数据可以从各监控、日志系统获取；数据源之上是运维管理总线，提供数据的接入、缓存、预处理，以及各个系统之间的消息传递、API 调用，这一层通过搭建异步消息总线如 Kafka 集群来实现消息交互；第三层是数据处理层， 包括两个方面， 大数据平台提供的是数据流式解析 （例如数据加工、实时告警），数据计算以及存储能力，智能算法层主要提供、训练各种智能算法模型；数据处理层之上是接口层，根据不同的智能化运维场景提供接口调用，主要提供 API 的注册、接口网关、状态、调用的管理，数据网关主要提供数据的查询，数据网关等功能，接受 AIOPS 的总体调度；最上面一层是AIOps 场景层，该层次是通过调用 API 层提供的各种能力来实现智能化场景。
AIOPS 场景层的设置是根据事件的生命周期进行设置的，例如在发现问题阶段通过自动基线、通过日志分类来判断异常，发现问题；到通过关联分析、日志深度检查、应用全链路监控等来分析问题；通过匹配运维知识库，实现智能问题定位；同步进行智能预测来预测容量、 故障的发生， 同时提供辅助决策的功能。
7.6.2 智能告警
告警的本质是发现问题、分析问题、解决问题。若告警太多，则可能因信息量过大，无法快速识别有效信息。本文方案的智能告警主要是四个方面，告警信息的压缩（去重去抖动）、收敛（概化和降）、预测（发现潜在问题）、异常检测（自动生成告警阈值）。
云基础设施下应用往往能够自愈，为便于分析处潜在问题，应及时采取预防性维护措施；本文方案智能告警阈值实现动态基线、动态阈值功能，支持对任意基于时间序列的 Metrics 进行异常检测和告警， 也可通过应用系统拓扑和分类算法进行根因分析，快速定位到问题的根源所在。同时告警通知内容经过优化，向运维人员清晰、全面的描述引发告警的根源和由此造成的影响， 为一线运维工程师提供基于告警事件的智能处置建议，在故障处理后自动完善运维知识库。
7.6.3 智能故障分析
通过规则或经验值来判断是指标否异常偶尔出现个别异常点， 不一定定意味着异常。本文方案通过降低抖动、噪声、周期性任务对检测结果的影响，基于自适应无监督集成算法，针对不同的数据格式（稳定性数据、周期性数据、突变数据等）自适应；针对不同的异常具备鲁棒性（时域、频域，突变异常等），识别出 IT/业务指标的周期性，降低抖动、噪声、周期性任务对检测结果的影响，通过智能算法找出导致系统异常和故障的根源。
智能故障分析设计
方案同时利用容器云的弹性资源池作为算法运行的基座， 充分利用云基础设施优势，提高基础设施资源利用率。
7.6.4 智能故障处理
应用云化部署后，服用容器云资源池，故障分析较传统基于服务器部署时更具挑战， 本文方案智能故障分析基于应用系统拓扑信息和分类算法进行根因分析，数据源来自日志、报警、知识库处理方案，自动编排故障处理流程。如资源出现故障时，根据 CMDB 的关系海洋和资源图谱，以图形化的方式展现资源所影响的业务， 运维人员分析故障对业务的影响情况， 给出故障解决优先级， 处理故障。
同时在分析过程中基于集群高可用分析、故障等级自动计算、 业务影响多维分析、日志） （OS 日志、网络日志、中间件日志、应用日志、环境日志）分析，基于 CMDB 将应用 Pod 分组，对故障可能性进行聚合加权排名。
基于已有的运维数据通过机器学习的方法， 进一步解决自动化运维没有办法解决的问题， 自动从数据学习中总结规律， 并利用规律对当前环境给予决策建议。
7.6.5 IT 架构可视化
本文方案的 IT 架构可视化基于 CMDB 及持久化层的运维大数据进行系统运行态架构展示，以系统运行态架构（部署层次、网络拓扑）为图，图上的各元素接入运维大数据平台的各监控数据源的数据，进行集中展现。结合 IT 架构可视化及多类数据源，运维人员可更为快速、精准地定位故障。
7.6.6 自动化运维
应用上云同样需要容器云资源池管理分配， 基础技术平台的中间件服务运维管理，本文方案自动化运维系统调用“基建层”和“PaaS 层”的接口，实现以下自动化能力：
运维基础数据自动收集：Pod 等资源的 CMDB 信息自动录入、开源软件补丁信息搜集；
应用上云资源自动管理：容器云平台配额分配，存储资源 PVC/PV 自动分配；
基础技术平台服务自动供给：自动创建 Redis、Kafka 等公共服务，应用服务配置化；
应用下发及版本自动管理：应用的 K8S 资源（或 CR 资源）自动更新，镜像自动更新，记录应用多系统软件下发关联关系，实现依次下发及依次回退；
故障自动维护：实现异常状态容器化运行的应用、中间件自动重启（应对健康检查、调度、Job 资源僵死等）；自动生成工单，审计故障处理记录；
7.6.7 预测与决策辅助
本文方案 AIOPS 平台对工单系统中对操作行为审计、学习；对工单内容的逻辑和语义进行事前复核，对工单操作过程中的关键步骤进行推送，针对故障处理类工单根据故障处理的知识库推荐给用户相似的故障处理意见， 并在故障处理后对知识库自动完善。
8 企业级云原生知识体系建设
知识库属于知识管理的特殊数据库， 需要对领域内的知识进行采集整理提取，知识库需要提取关键的信息来建设， 本文方案构建的云原生知识库， 有以下特点：
自助服务：知识库面向每个人，每个人都可以访问知识库自助查阅相关资料；
知识复用：同一个问题在同一个地方都有同一个解决方案，同一个知识可以服务不同需要它的人；
降低成本：知识库是自助、复用的，不需要太多人力参与到技术支持服务中，降低了人力与时间成本；
开放协作：知识库是开放的， 任何人都可以参与知识库的构建与完善中，为保持科学严谨，需要一定的审核制度；
规范统一：对同一个事件，知识库对任何人的展示都是一样的，有利于处理问题的过程中做到规范和统一；
经验传承：每个业务研发项目都有自己的系统特点与独特问题，针对性问题的解决方案得以传承；
本文方案以赋能业务项目组和团队能力提升作为核心价值建设知识库， 以自助服务、开放协作、规范统一的特性作为核心，建设 Wiki 知识体系、ChatOps搜索体系、云原生文化体系，来完善知识库。
8.1 云原生 Wiki 设计
本方案基于 Wiki 来建立云原生知识库， 通过树形目录分类将不同的 Wiki 进行分类，基于云原生基础知识体系、云原生基础平台使用和云原生核心技术研究三个方面来建设：
基础知识教程模块：体系化的技术课程教程， 提供体系化的学习课程，内容包含课件、 视频；
平台使用模块：平台的使用手册，每个子模块都包含使用规范、问题排查、高级特性、安全规范、上线相关；
研发技术模块：非公开知识库云原生团队内部使用，记录内部研发的方案设计、技术分享、疑难问题等
➢ 容器研发
➢ 微服务框架
➢ 疑难问题
➢ 运维步骤
本文方案为了规范统一，提高知识的正确性和有效性，设计了知识编写、知识审核、知识推广、知识反馈来组成知识管理的生命周期，持续迭代知识库，提升 WIKI 文章质量和易用性。
云原生 Wiki 知识迭代体系
知识编写“开源”：上云知识库的编写主力是容器云基建层、PaaS 层、DevOps 建设的研发人员， 但也需要集团科技人员的自发贡献；平台使用模块的Wiki 会直接关联到相关团队的电子看板代办，作为其工作的一部分；基础知识教程模块的 Wiki 完成编写后会持续根据外部会议、技术更新进行迭代更新，同时也会发布 Wiki 编写任务，各科技岗人员均可以认领编写；
新增内容审核机制：知识审核的工作是知识库的立足之本，需保证每一篇 Wiki 的质量才能让知识库良性循环推广越来越多，但是知识审核的工作又存在复杂性和专业性；本文方案基于 Confluence 的空间分组来区分审核区 Wiki和公开 Wiki，整个审核主要针对于基础课程模块，其余模块的正确性主要基于知识反馈阶段来迭代增强；
知识评价体系：知识发布阶段将基于 Confluence 的评论、点赞、浏览数对 Wiki 进行准确性、有效性的评价，对于浏览数少，点赞数少的 Wiki 将进入知识迭代重新更新；
知识迭代流程：对于知识评价阶段需要修改的 Wiki 和技术更新需要更新的 Wiki 将进入新的迭代周期。
8.2 ChatOps 构建知识搜索体系
本文方案为了提高信息的流动性，设计了以 ChatOps 为核心的知识搜索体系，IM 系统对接 WIKI 知识库，提供 WIKI 搜索的能力，智能机器人可以提供Q&A 解答已有问题， 无法解答的问题会分派到 SLA 云原生技术接口人进行问题解答并补全 WIKI 和 Q&A 知识库。
知识搜索体系
本文方案设计了知识搜索体系，将 Wiki 知识库集成到 IM 系统中，建立完善的知识库搜索体系：
分词系统：处理 Wiki 标题、内容和评论中的内容，进行分词和关联，筛选标签，建立 Q&A 倒排索引表写入 ES。
全文检索：基于 ES 提供 Wiki 搜索的标准 API。
问答机器人：在线问答机器人对接 IM 系统提供知识库搜索的功能和接口人分配的功能；对于无法查询到的问题由接口人解答后也会进入分词系统建立 Q&A 索引表。
8.3 云原生文化建设
知识体系建设中知识库作为核心存在， 但是在企业中进行知识库的建设和推广需要人作为核心进行一系列活动。银行内进行技术转型，本文方案设计部分适合中大型银行的推动技术转型的运营方案，将云原生文化融入到企业文化中。
云原生文化建设
方案包含在银行内组织容器运维工程师认证、云原生研发工程师认证、优秀课程比赛、技术研究分享为核心的技术类活动，活动银行内信息系统架构云转型的目标进行，推动云原生文化的普及。
9 云原生标准建设
9.1 高阶指引
云原生体系首先要建设高阶的指引。
9.1.1 应用上云适用指引
该指引主要明确哪些系统需要上云，系统的哪些组件需要上云，比如数据库组件、Redis 组件是否需要上云。
9.1.2 应用上云设计指引
应用上云不能仅仅是把传统应用直接搬到容器上， 需要根据云的特点进行设计，充分发挥云的优势，因此需要制定应用上云设计指引，指导架构师如何对应用上云进行设计
9.2 研发侧规范
9.2.1 应用容器化设计规范
应用配置中不指定 Pod 的 IP
应用容器化部署后，Pod 的替换伴随着 IP 的变化。若应用指定 Pod 的 IP访问目标应用，一旦目标应用的 Pod 发生变动，目标应用的 IP 也会随着变化，目标应用将无法被正常访问。为了保证应用访问服务的稳定性，应用中不直接通过 Pod 的 IP 来访问目标应用。可以通过注册中心，获得动态 IP 的方式来实现服务间的调用，也可以直接使用 serviceIP 来实现不同应用间的调用。
同一 Pod 内的不同容器间使用环回地址相互访问
同一个 Pod 可以有多个容器，这些容器共享同一个网络命名空间，它们之间推荐直接使用环回地址来实现互相访问。
为应用实例提供健康检查接口
应用需提供健康检测接口，用来配置容器的健康检查策略，从而保证滚动升级过程中的服务可用性。
应用容器需要考虑优雅退出
为了保证应用服务的稳定，应用容器需要考虑优雅退出，确保容器退出时关闭所有连接。如果应用程序未处理 SIGTERM 信号,可以在编排文件中设置preStop Hook,即在关闭容器前等待一段时间，让应用程序完成所有请求。
使用 CronJob 代替 crontab 服务设置定时任务
不建议在容器中使用 crontab 服务设置定时任务，推荐通过 CronJob 资源对象来实现定时任务的功能。
9.2.2 应用编排规范
应用容器通过使用 PV/PVC 进行持久化数据
容器本身并不带有持久化存储，被销毁时容器中存储的数据也会被清理。容器中如果需要保存数据，需要通过 PV（持久化卷）与 PVC（持久化卷请求）资源，使用 NAS 存储，实现数据持久化。
ConfigMap 挂载到容器内部的文件夹必须为空
配置文件可以保存在 ConfigMap 中，ConfigMap 挂载到容器内部的目录会把目录下的原有文件覆盖，所以需要注意挂载的目录尽量为空目录。
为应用实例设置健康检查
为了更好地监控应用服务的状态， 充分发挥云原生基础平台为应用带来的自愈能力， 提高应用的可靠性， 应用必须设置 readinessProbe 与 livenessProbe。其中 readinessProbe 将检测应用容器是否已准备好接受流量，livenessProbe将检测应用容器是否存活。
为应用实例设置资源限制（cpu 与 memory）
为了对资源进行精细化管理与控制，减少底层资源的竞争，也可避免程序因Bug 占用过多底层资源， 以提高应用的稳定性， 容器基础平台的应用部署时必须为每个容器设置资源限制，包括：limits.cpu、 limits.memory、 requests.cpu、requests.memory。其中 limits.cpu、limits.memory 为应用运行过程中占用CPU、Memory 资源的上限值；requests.cpu、requests.memory 为应用运行过程中请求的 CPU、Memory 资源值。
9.2.3 应用镜像构建规范
使用基于安全构建的统一的基础镜像
基础镜像涉及应用运行所需要的安全可靠的 Linux 操作系统。基础镜像由基础架构部门负责维护，定期打安全漏洞的补丁，并基于应用要求构建基础环境镜像，维护到公共镜像仓库。
镜像一次构建，多环境部署
为了保证应用的运行环境保持一致，应用容器镜像应在研发环境下构建，在其它环境下部署进行测试与上线均使用同一个镜像。
使用非 root 用户启动应用容器
为保障云原生基础平台的安全性， 禁止应用容器中使用 root 用户运行应用。
9.3 业务上云交付规范
9.3.1 需求管理规范
云原生体系既带来了企业技术堆栈的升级换代，也带来了应用交付、管理模式的全面升级，应用建设一般采用敏捷模式，以更加快速的迭代周期开展，在上云交付规范中，企业需先建立适应云原生体系的需求管理规范，在需求来源上，可结合领域建模和事件风暴等模式，形成迭代的用户故事地图，并借由电子看板等先进工具进行迭代的管理。电子看板可视化业务价值的交付过程，是一种需求流水线，同时其与各能力集成，实现智能化更新需求所处阶段。
数字化需求管理
9.3.2 质量控制规范
在云原生体系下，应用的交付变得敏捷而又快速，随着建设、部署的自动化程度提高， 传统的质量控制手段技术和方法可能会成为影响应用发布效率的关键因素，故在云原生体系下，需建立更加智能、自动化的质量控制体系，一般最佳的实践是将各类质量控制手段、方法固化在整个 DevOps 流水线过程中，设定各个环境的质量门禁，以达到自动、智能的质量控制，同时通过各个环境的信息反馈，进一步优化门禁质量。
自动化质量管理
9.3.3 镜像准入规范
公共镜像原则上仅包括一种中间件软件。若同一公共镜像需要包括大于一种中间件软件，必须采用多次构建方式。
应用镜像必须使用镜像仓库统一提供的基础镜像或公共镜像构建。应用镜像必须符合精简原则， 应包括且仅包括针对公共镜像的配置修改、 可执行的应用包、依赖包介质和启动命令，不得包括其它与应用无关的文件。应用参数配置文件不应包含在应用镜像内部。
9.3.4 镜像命名规范
镜像命名使用小写字母， 避免下划线， 最长 64 个字符， 每段命名间使用“-”连接。
格式如下：<team>-< scope >-<tech>-<maturity >-<locator>
其中：
1. <team>指项目组或系统，可自行定义，避免使用下划线。
2. <scope>指镜像库的依赖范围，可填选项为一方库、二方库、三方库。
3. <tech>指采用的技术或包类型。每个仓库中应保持同一种类型的二进制文件。
4. <maturity >指镜像库的开发成熟度，例如开发、测试和发布阶段。
5. <locator>指镜像库所处的物理地点。
9.3.5 镜像安全管理规范
定期对制品库中的镜像使用 Jfro X-ray 进行漏洞扫描，存在高危漏洞的镜像责任耽误需限期内完成升级，如容器云建设团队维护基础镜像、PaaS 层建设团队维护中间件镜像、各研发团队维护各自的应用镜像。
9.3.6 应用发布与回退规范
应用的发布需在自动交付平台完成全部的安全合规审查流程；
应用发布需全面接入 PaaS 层的监控、日志平台、服务治理平台；
需根据应用的特点分配其带部署的集群类型 （CPU 密集型、 内存型、 GPU型）；
应用发布默认情况至少在 2 个集群进行镜像部署，用于抵抗集群层面故障风险；
根据应用的业务特点适当进行在离线混部，提高物理机资源利用率；
每次应用交付的 Yaml 编排需存档审计，每次应用更新之前通过自动化运维能力导出正常运行的当前版本的全量 Yaml 编排， 下发失败时自动基于全量Yaml 进行回退。
9.4 运维侧规范
9.4.1 基建层定期巡检
设定定时任务对K8S集群关键组件运行状态进行检查， 按时生成巡检报告，以邮件形式发送至平台运维、 研发单位。包括：Api Server、 Controller Manager、Etcd、Ingress、Kube-OVN 等组件状态以及集群备份状态和证书有效期等。
9.4.2 基建层应急预案
根据 K8S 集群特点，制定应急预案：一是记录硬件资源、软件资源、集群逻辑架构、数据备份方案、关联系统、应急联系人等信息；二是记录系统节点及部署模式， 便于故障发生时快速查阅节点信息；三是针对平台层故障场景 （虚拟机、硬件、网络、平台组件）、应用层故障（容器应用、定时任务等）场景的处置方案，以及故障恢复后的验证方案；四是针对集群层极端场景的故障。
其中平台层故障处置方案主要有以下三个层面：
基础设施故障：虚拟机节点故障、物理主机故障、基础网络故障、存储设备故障；
平台服务故障：计算平面各集群管理节点组件服务异常（API Server、Controller Manager、Etcd），工作节点服务异常（Kubelet、Kube-proxy），网络异常（Kube-OVN 服务），存储服务异常（Longhorn服务）；控制平面 Karmada 服务异常；
运维相关应用故障：监控服务异常（多机房监控服务），日志服务异常（集中日志平台服务），集群容灾服务。
9.4.3 基建层定期容灾演练
容器云基建层需定期进行几个方面的容灾演练：
服务器硬件故障时单集群容器自愈能力；
全局负载相关网络硬件故障的网络容灾能力；
一个容器云集群雪崩时的应用跨集群恢复能力；
机房故障时控制平面集群容灾切换能力；
9.4.4 性能容量管理
记录周期内业务系统对容器云资源池申请及资源使用的情况，周期性进行基础计算、存储资源扩容；
根据业务应用运行特点，在上线稳定后开启 HPA 或 VPA 能力，重分利用基础设施弹性，提高物理机资源利用率；
10 总结与展望
本文方案基于题目需求为中大型银行设计了一套系统、全面、合规、可靠、具备扩展性的云原生体系。
通过金融级的容器云存储、网络、多云管理及容灾方案打好基座，即支撑PaaS 层日志、监控、开源中间件服务、多云异构微服务治理能力，也可支撑应用上云即具备多集群高可用能力。在交付层面，通过云原生应用开发平台一键为各技术架构应用提供“一键”云原生改造功能，自动便捷接入下层 PaaS 服务；
基于企业级制品库实践 DevSecOps，做到交付高效合规。运维体系方面，围绕“自动化” 、 “智能化” ， 设计适配云环境的 CMDB， 通过 EBPF 增强可观测性，打造 AIOPS 平台提升运维效率。制定研发、交付、运维各阶段规范，通过规范约束各环节用好本文方案整体技术能力，充分发挥云原生效能，实现降本增效。
本文方案在技术选型上一方面基于 CNCF 开源项目，同时也基于金融行业高要求选用具备一定大规模企业落地实践的方案， 适合具备一定技术掌控能力的中大型银行。此外方案通过设计可扩展的 PaaS 层能力和云原生应用开发平台为Serverless 奠定了基础，未来在智能化的业务混部、智能化的调度和伸缩方面进一步扩展，基于 Serverless 实现云的极致弹性和敏捷。
原题：2021 容器云职业技能大赛团队赛冠军作品——适用于大中型银行的云原生技术体系建设方案 如有任何问题或需要下载原文档，可点击文末阅读原文 觉得本文有用，请转发或点击“在看”，让更多同行看到
2021 容器云职业技能大赛更多获奖作品
请扫描二维码
欢迎关注社区 “容器云”技术主题 ，将会不断更新优质资料、文章。地址：
https://www.talkwithtrend.com/Topic/98447
下载 twt 社区客户端 APP
长按识别二维码即可下载
或到应用商店搜索“twt”
长按二维码关注公众号
*本公众号所发布内容仅代表作者观点，不代表社区立场